Perhaps more interestingly, this lets you animate texture coordinates. (To give one example, this could be used to define a smooth clientside tile animation inside model files.)

This would be especially useful for animating facial textures. Will this need SSCSMs given the "clientside" nature you mention or will there be server-side API to control this too?

This would be especially useful for animating facial textures. Will this need SSCSMs given the "clientside" nature you mention or will there be server-side API to control this too?

Right now it's just a model feature, these are just normal animations you'd set with ObjRef:set_animation.

Tried this setup:

And got this error:

2025-06-16 03:15:58: ERROR[Main]: Irrlicht: error converting gltf to irrlicht mesh: model requires extensions, but we support none
2025-06-16 03:15:58: ERROR[Main]: Irrlicht: Attempt to load mesh failed: morph_test_cube.glb
2025-06-16 03:15:58: ACTION[Server]: singleplayer [127.0.0.1] joins game. List of players: singleplayer
2025-06-16 03:15:58: ERROR[Main]: Irrlicht: error converting gltf to irrlicht mesh: model requires extensions, but we support none
2025-06-16 03:15:58: ERROR[Main]: Irrlicht: Attempt to load mesh failed: morph_test_cube.glb
2025-06-16 03:15:58: ERROR[Main]: GenericCAO::addToScene(): Could not load mesh morph_test_cube.glb

If I disconnect the mapping node the cube plays normal animation (pulsating cube) but then of course texture animation is lost.

All files are here: https://files.catbox.moe/cbwps2.zip

EDIT: I can confirm though that normal morph targets (blender shape keys) export properly in animations.

It appears that to export UV animations from Blender the KHR_texture_transform extension is needed.

Closing thought:

The use cases for morph animations don't really seem to be there at the moment. The use case that initially motivated me turned out to need other features, at least for a standard workflow.

So I stopped working on this. I should maybe have closed it earlier, but it was just a draft anyways. It makes sense to prioritize implementing other features, e.g. multi-track skeletal animation, or better material support.

If anyone would find morph animations to be particularly useful, feel free to drop a comment explaining what you need them for and I might pick it up again.

If anyone would find morph animations to be particularly useful, feel free to drop a comment explaining what you need them for and I might pick it up again.

Morph targets (also known as shape keys or blend shapes) are a standard feature of most self-respecting game engines and are used for deformation corrections and e.g. face animations which would otherwise need a complex bony rig. Even with low-poly models you can make precise animations of flat layers that emulate eyes or face (I know artists which use this technique for their ps1 style models).

I agree that hardware skinning and non-linear animations have priority over this, but morph targets should still have a high priority.

I agree that hardware skinning and non-linear animations have priority over this, but morph targets should still have a high priority.

Thanks for the feedback, I'll take that into account and probably pick this up again once there's progress on the other PRs.

Not really related, but since you're already sharing your priorities: Where would you put better material (PBR) support, and which properties do you consider especially important? See https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#materials for the relevant glTF features, comment on #8854.